Option to show line numbers in editor

giteshsharma · 2020-05-02T07:33:25.720Z

tessus:

but it was decided not to merge it.

Why So?
I think many users including me need that feature in Joplin.

Points to consider

RN there is no splitscreen in Joplin then how should one comapre the large notes?
I can use online site for that but if I have just check for 4-5 lines in both notes then Isn't it useful to use such an feature so I can check line number of notes?
We have syntax color for code then it will be great for code as well
If I transfer my notes from text editor such as notepad++ or atom text editor or sublime then they have line number and it will be great if Joplin have this feature too.
Many users have habit of that line numbers like me, @pid, @jannes and other wants that as well.
We know that Joplin is a big community and getting bigger, we are having users from every field. For example Writers like @randke, bug hunters like @worker and others, probably writers don't need that line number but bug hunters need that, even I do bug hunting so I need that feature, current I use atom editor for that.

Best part it @tessus's PR is ready to merge and it is an option not compulsory for all users

I checked the past posts and this feature wanted by many users, I think @laurent should reconsider this feature. It will enhance Joplin for different type of user.

tessus · 2020-05-02T22:49:31.299Z

This is a very complicated topic. The project was created by Laurent, because he needed a note taking app that suits HIS needs. Over time it developed into a project that many people rely on.

Yet, Laurent is still the single authority on what goes into the project. I can understand both stances very well, but I think as long as there’s a proper balance, we don’t have to worry that the project becomes unhealthy as it did with Gogs. Gogs was forked and most people now use Gitea instead, because the owner was just too stuborn to understand certain requiremenrs of users.

I have to admit that I’ve sometimes struggled with Laurent’s decisions, but when thinking about them for a while they made perfect sense. Laurent is not an unreasonable person, so if you make a strong case it will certainly be considered.

While I personally would love to have as many settings/options possible, I also do understand the UI design principles to minimize those optioms. There was this saying decades ago “Is there life after death? I don’t know, but I’m sure there’s way to configure that in vi.”

I’m sometimes very impulsive and I’m glad that Laurent pulls me back to the ground.

There are still very few issues I don’t agree on, but that’s why I have my own branch which I rebase every time I create my own release. But this is the beauty of open source. You can get stuff into a product or you can maintain your own branch.

Joplin is a great project and the community is outstanding. Great ideas, great points for discussions, and we all work towards an app that makes our lives easier.

jannes · 2020-05-03T09:28:17.187Z

giteshsharma:

I think many users including me need that feature in Joplin.

I agree, can't really imagine anyone using Vim without line numbers,
how else are you gonna navigate?

Since there are Vim bindings, I assume there are enough people who wanted this feature such that it was considered important enough. Then I can only imagine that the majority of these users would also very much welcome support for line numbers.

Of course it should be an optional setting like implemented in @tessus PR.

AtBios · 2020-05-04T07:39:42.035Z

There might have been a good reason for not implementing it though. I mean, I also see the usage of it, but at the same time not something I miss. Does something like Evernote support it? Because (this is just what I believe) this is more leaning an Evernote alternative and not something that supports everything that most common day to day users wont need.

Once again, this is just how I believe it is made. But Laurent would obviously be able to answer to his philosphy. I just see the reason for not adding tons of extra features (however small they may be), because in the end it is still more features that can break and needs to be supported.

laurent · 2020-05-04T10:13:01.248Z

I think @AtBios said it all - line numbers and I feel even vim/emac support is a very niche feature that only a few users need. And on the other hand it’s never free to add a feature - well it’s usually easy to add it, but it adds a permanent long term maintenance cost. And that cost is fixed whether it’s something used by 2 users or by 10,000 so that’s why we need to focus on the features with the best ROI.

Eventually I would like to create a plugin system that will allow adding this and other specialised feature to the app, without increasing the complexity of Joplin core.

AtBios · 2020-05-04T10:23:28.907Z

laurent:

Eventually I would like to create a plugin system that will allow adding this and other specialised feature to the app, without increasing the complexity of Joplin core.

That sounds like a great idea (but also a lot or work. :D), however, it makes sense. Since then the app could be the core updated and for plugins that only a few users really use/need they can keep them in working condition since it all is open-source.

giteshsharma · 2020-05-04T17:08:48.915Z

laurent:

but it adds a permanent long term maintenance cost.

Yes, I forgot about this.

laurent:

Eventually I would like to create a plugin system that will allow adding this and other specialised feature to the app, without increasing the complexity of Joplin core.

This will be indeed a great feature.

mick · 2020-05-04T19:09:47.474Z

Why don’t you just press Ctrl-E and let your note open in your full blown (g)vim installation, with all your settings and plugins?
I never understood why there was an internal vim editor included into Joplin. The vim-users won’t like it, cause it misses all the nice features, and the rest does not know how to use it.

That’s why I press Ctrl-E, edit my note, and when I write and quit (g)vim, it saves the note in Joplin.

leobard · 2020-05-07T06:23:58.249Z

Joplin is primarily an intuitive to use note-taking tool.

The content to write is the primary goal (a shopping list, an article, … usually with a focus on the words and their meaning). The majority of users (I assume) has no benefit by line numbers.

Line numbers are of use when debugging (“syntax error in line X”), which we are not doing. And for the VI(M) users amongst us who need them for the shortcuts to work. This is a minority of users who can use other tools much better suited for that.

I want Joplin to be a user-friendly and well-maintained tool for the coming decades and to accomplish that, we have to care that it stays attractive for the majority of users who want note-taking. Adding features for a small minority (us programmers) would add the cost that we have to maintain them and that they slow us down when we have to refactor the code for new and upcoming features.

Therefore I add one comment: “no line numbers, not even optional” is a coherent decision in my view.

shantanugoel · 2020-06-11T15:50:03.758Z

Recently, code mirror was added an editor in Joplin. Code Mirror supports line numbers natively without any plugin. Would it be feasible now to enable this as an option?

tessus · 2020-06-11T16:53:48.854Z

Same thing as with Ace. Ace also supports line numbers without a plugin.

shantanugoel · 2020-06-11T18:05:52.286Z

Ah, Thanks. I seem to have misunderstood the discussion earlier and thought that the implementation of line numbers itself added complexity to the code. Now, I understand that this is more about limiting options to configure so that remains simple. I can get why this can be an issue.

I miss having line numbers a lot in Joplin and have to edit in external editor (vim) a lot, which is a painful friction. Will wait for the possibility of either Laurent coming around to accepting this feature or enabling a plugin system where we could do it ourselves

laurent · 2020-06-11T18:17:57.797Z

Yes on one hand I think this is a reasonable request, but on the other hand I prefer not to keep adding more options for features that are not “core”.

That’s why some way to extend Joplin, maybe via plugins or some API, would be great. It’s relatively high priority to do so, so that new features can be implemented as plugins, thus freeing resources for core development.

laurent · 2020-06-17T23:58:46.644Z

I’ll give another try to the plugin system as I think that’s what gives the most flexibility to customise the app. As a test I’ve created a plugin that simply sets the lineNumber option, and that works well and it’s simple: https://github.com/laurent22/joplin/pull/3257/files#diff-4a986d198b86e2f167692a694e3fe263

So that’s most likely how the development will work now - on Joplin core we add ways to extend the app by providing hooks and event handlers, and then any non-core development can be done via plugins.

jannes · 2020-06-18T14:10:30.574Z

thanks for your work on supporting plugins, i think this is a great addition and a good compromise:)

shantanugoel · 2020-11-06T20:23:34.778Z

Thanks for the new plugin system, Laurent. If possible, could you or someone else please help to create a plugin for turning on the line numbers? I'm afraid I don't know much of JS and I tried using the code from your earlier commit above but that didn't seem to do anything.

Code that I used from your commit.

joplin.plugins.register({
	run: async function() {
		joplin.filters.on('codeMirrorOptions', (options:any) => {
			return { ...options, lineNumbers: true };
		});
	},
});

jannes · 2020-11-12T08:50:25.182Z

Would also really appreciate that,
I have been trying to implement this, but looking at the API docs
I couldn't find out how to do it exactly.

joplinapp.org

joplin.settings | Joplin Plugin API Documentation

Here it says " Note: Currently this API does not provide access to Joplin's built-in settings. This is by design as plugins that modify user settings could give unexpected results".

This means only the settings that are available for the user to change in the application, right?
So changing the 'codeMirrorOptions' should still be possible?

laurent · 2020-11-12T11:42:37.264Z

The "codeMirrorOptions" API mentioned above was experimental and has been removed. It's not clear yet how to modify this kind of settings with the new plugin system, but we'll get to it at some point.

PhiLho · 2020-11-14T12:36:40.423Z

Quick hack in userchrome.css:

.CodeMirror-code
{
	counter-reset: line;
}

.CodeMirror-line:before
{
	counter-increment: line;
	content: counter(line);
	width: 2rem; /*  Adjust if you have lot of lines, big numbers */
	display: inline-block;
	padding: 0 0.5em;
	margin-right: 0.5em;
	border-right: 1px solid #DDD;
	color: #888
}

Looks a bit strange on long, wrapped lines, but might be usable.

image646×640 23.9 KB

shantanugoel · 2020-11-27T18:15:42.935Z

So, I noticed that CalebJohn recently added support for code mirror content script plugins to Joplin. Spent some time on it and was able to create the line number enablement plugin
Anyone else interested can get it from here: Release 1.0.0 · shantanugoel/joplin-plugin-cm-linenumbers · GitHub

Code is at: joplin-plugin-cm-linenumbers/src at main · shantanugoel/joplin-plugin-cm-linenumbers · GitHub