In the spirit of Open Dialogue - Avoiding the - Yet another Plugin?

#21
  • Really find it hard to see the “condescension in my words” so to move forward either;
    • help me understand, ideally privately if you want to be frank and avoid flame wars
    • or people need to stop reacting emotionally to the contestation of ideas.
  • Well we have to agree to disagree, all I can say to this is, there are personalities in our community who are prickly to deal with. They respond quickly with emotional fervour, anger and sometime silently black list others without even asking the author, source of their distress “what they meant”.
    • This is of course part of the natural diversity of people.
    • But it does not mean it is right to "respond quickly with emotional fervour and anger.
  • It is very difficult to write useful criticism’s of intellectual arguments without sometimes using words that people of different backgrounds may misunderstand.
    • This thread is an example and why I call for a little more generous consideration of what people say.
  • The problem here is that if the claim that the “That communication seems dismissive or harsh,” is made, it is then difficult to contest it.
  • Basically the first negative response
  • Once someone responds emotionally to someone else’s comments without first requesting clarification, it puts the author in a difficult position. This is I believe what has occurred in this thread.
  • I was after all only offering a view point, I did not accuse someone, I did not insult someone personally.

My next post is about the OT and if anyone is still listening I would appreciate your perspective about the ideas not the person, “me” in this case.

#22

In summary I said In my view when we come across a tiddlywiki limitation we should endeavour to return to the core and identify the limitation and address that rather than writing another plugin, and in particular the less accessible JavaScript plugins.

  • From my experience the core contains substantial resources already and most gaps can be addressed by a minor tweak or extension to existing code.

Two examples;

  • The core does not provide a tiddlywiki serial date picker, or simple date arithmetic, @EricShulman’s comprehensive date tools address this but arguably these key features should be in the core. Over the years I have seen a few dozen attempts to address this but all in plugins. As a result the core still does not have a simple date picker or date arithmetic.

Another example is being able to transfer a complex or simple filter into an easy way to search, export or delete those tiddlers.

TiddlyWiki already has this built in, but not available, see Control Panel > Info > Basics scroll to the bottom and you will see;
Snag_60c9e4

  • If you click in any of these the filter is transferred to the Advanced Search > Filters tab
  • The macro that does this show-filter-count(filter) is defined in $:/core/ui/ControlPanel/Basics but not usable elsewhere.
  • Here I externalised this macro in show-filter-count.json (975 Bytes) and added a parameter to show/hide the count.
    • Thus you can now do <<show-filter-count "[all[shdows+tiddlers]tag[$:/tags/Macro]]">>
  • Once externalised the original definition can be deleted reducing the size of the core tiddler $:/core/ui/ControlPanel/Basics
  • Then all we need is to document the macro.
#23

I did give you an answer to your original post in my reply, but since you may have skipped over it here is the general idea: putting aside the assumed value judgement about a wikitext contribution having more value than a javascript contribution, adding everything to the core so wikitext covers every instance where someone would want to use javascript would introduce a lot of unnecessary bloat and part of the beauty of tiddlywiki is how flexible the plugin system is. The core can, and in my opinion should, be as small as possible for both aesthetic and technical reasons.

The only problem that I can see with having many plugins available is that we don’t have a good method for discovery of community plugins yet.

3 Likes
#24

@inmysocks I did read you reply in full, thanks, but it would have being quite involved to give you a full and comprehensive response, and simultaneously avoid being miss read by anyone. Although I have read and deeply considered your views. I also concur with most of what you said, except perhaps what I did actually reply to.

  • To be sure, what I said has being missrepresented by others a number of times.
  • Agree with this whole heartedly but I also think such a resource could be tied to essential core features, especially if the core is not going to address these for example if we must use a plugin for date picking then lets document the community resource for date picking in the documentation.

As an example your Bob and Bob.exe are to me, key features needed in tiddlywiki, I personally would like to see it or a version of it in the core plugins at least because you have addressed a substantial gap. You also deserve some relief from maintaining this on your own.

  • If some of the key affordances were in the core (or core plugins) bob could be simplified, and easier to maintain.
  • I am glad you did put this aside because I did not say or argue that at all.
    • Its not a value judgement when a JavaScript Plugin is the solution and the core already handles it effectively. Simply put the Plugin is “redundant”, and unnecessary.
  • As I think with your experience you also know on one hand there are things best left out of the core and others that by nature demand a plugin and none of us want bloat, and on the other hand some belong in the core.
  • My key argument is there is little encouragement to ask for and seek gaps in the core to be addressed, resulting in numerous plugins each taking their own approach to addressing the gaps.
    • Of note here is @jeremyruston and other core developers do actually identify such cases and improve the core, this happens every new release. It is also a bit much for them to take responsibility for identifying and filling every gap. Some of which they never see because they don’t see the gap given their knowledge they can do a work around.

My point, missed by many, is those with both advanced tiddlywiki skills (I count myself amongst them) and JavaScript skills are the people we need to identify the gaps for which core tweaks and features can be achieved with little or no bloat.

  • To use JavaScript in tiddlywiki requires some understanding of integration in TiddlyWiki this same knowledge, is what we need to use to improve the core.
  • But there are many cases where we do not need JavaScript code
  • For example look at how the small amount of code to define the cascade filters has resulted in substantial increased hackability. Most of that solution is wikitext, widget and macros. The Gap was the cascade operator.
#25

I was referring to the first 15 minutes … I do like Douglas Crockford’s presentations. There always is a lot of history info. The rest of the talk is relatively technical.

#26

This statement is just not true.

as shown in these two quotes

you may not have meant it that way, but by refusing to acknowledge or address this it is impossible to have a reasonable conversation. In order to communicate effectively you have to accept that a viewpoint that isn’t yours exists and may be valid.

#27

Sorry, I have done enough “addressing of this”, and once again I ask a little generosity and compassion, in the way my words are interpreted, I explained what I tried to say, and returning to my original words without taking subsequent words into account is not fair.

And other people including yourself;

This is not a one way street.

#28

Yeah, I agree, my wife and I joke about this all the time. It’s the “You sound negative today!” “No I don’t!” “Aha!” problem.

Do you have a list of particular functionality that you’ve wanted or wished for? Do you have a list of gaps, in other words?

2 Likes
#29

If someone who is clearly competent enough ends up creating a plug-in that “reinvents the wheel” or whatnot, I would see that as more of a “failure” of the wider TiddlyWiki ecosystem. I think it is safe to assume that the plug-in developer would also have searched the documentation, and other locations, but still “failed” to find the relevant content to give them what they needed.

Being open to pointing the new developer to existing, relevant content only serves to make them more knowledgeable in the future; and could incentivize them to change course on their own plug-in to further extend TW capabilities beyond the Core or an existing plug-in.

2 Likes
#30
  • I could give a list, but people find them every day, that why I posted, I am hoping more emphasis can be put on identifying Gaps and addressing them rather than “patching them” with yet another plugin.
  • Because my core development skills are not so advanced I can not readily do fixes to gaps, I am also guilty of making the patches I complain about.
  • Although people would attack me for using the word “Failure” do they even understand I too admit to failing in this way as well?
  • This has being an unpleasant experience :frowning_face:
  • Thank heavens at least someone (actually a few do) know what I am talking about.
#31

For those criticising me on the use of the word failure look back and the OT source and see which individual may be the subject of my criticism, its ME.

What a “storm in a tea cup”

#32

Sure, but the emphasis (i.e. the bold) was not on you. The emphasis was placed on “the use of Javascript is a failure”. What is not bold is easily taken as being very very very secondary, and what is bold is the primary message.

Whatever you are trying to accomplish, it is coming across the wrong way. Pretty much every time you bring it up. Wording and emphasis matters.

However you bring it up, it often leaves an impression that people who use javascript in TiddlyWiki are actively doing something against the TiddlyWiki community.

If some folk prefer using javascript, let them be. Celebrate folk who choose TiddlyWiki and use it, however they use it.

I strongly suggest whatever you think would be good for TiddlyWiki, speak of that and take javascript our of the discussion because it is giving the impression that you have a dogmatic/obsessive disdain of people using javascript. That may not be what you want to express, but it is coming across that way.

1 Like
#33

Which features do you personally see as fundamental enough to merit inclusion in the core? That’s a genuine question: I follow the forum pretty closely and find a lot of inspiration as well as excellent, ready-made solutions here, but I see just as many well-designed plugins that are clearly vital to the people who make and use them, but would be completely unnecessary in my own work. To me, the modularity of the plugin system is actually one of the most appealing things about TW, and I appreciate our developers’ selectivity and commitment to keeping the core small. But I know you’ve suggested some core-level changes that would offer a lot of extra extensibility for end users and plugin developers (e.g. space for custom button actions), and I’m sure there are many more potential core improvements that aren’t coming readily to mind. So which current plugins or patches would you consider broadly indispensable?

3 Likes
#34
  • Impression or Not I do not hold this position.
  • Please read the whole sentence (annotations for clarity)

In my view (personal position) needing (having to do, because there is no other option, ie forced) to write a Javascript solution is often a failure (Indicating its worse than sub Optimal)

  • This is not about all JavaScript is about when being forced to use it.
  • My previous clarifications include
    • showing it was a criticism of my own choices,
    • That the core modifications may very well be JavaScript in nature
    • Pointing out there are very good use cases for JavaScript plugins
  • I will also add I have never seen you doing this thing I am warning against.

I am disagreeing with what you are saying about my words,

  • I doubt we disagree on JavaScript, except perhaps I suggest we need to add a little more emphasis to address gaps in the core, such as we are not forced as much to develop bespoke solutions in Wiki Text or JavasScript plugins.

I am warning against too many bespoke solutions, which I think is such a simple fact it perhaps need not be debated.

1 Like
#35

I read the OP almost as soon as it appeared.

But I took my time before replying, so that I could read it a few times over, so that I could be sure that my reaction was from an honest interpretation of what I read.

And such is this reply. Time and space to read, reflect, and recycle.

So, respectfully: Eat My Shorts - YouTube

#36

Advantage is much in the eye of the beholder.

My message to all of you creative folk out there:

  • The advantages to me in the thing you have built: it is useful to me, and it has me not caring one little bit how you built it. I only care that it exists, and that I can easily have it in my TiddlyWiki instances, that I can easily use it, and use it as-is without having to fiddle with it. Javascript or wiktext, I do not care. If I can use it with simple macro call syntax, I am good.

If you as a creator are concerned about making sure what you create can be altered by others, then yeah: you’ll have better chances sticking with WikiText. If you are not concerned about it, then do what works for you, please.

#37

Like it has been mentioned already, use of the word failure implied a tone / opinion others interpreted as disparaging. On the surface I (as a non programmer) felt it read as being presumptuous.

That being said I think it’s great wikitext is rich enough to not need to use as much pure JavaScript. It absolutely better for people like myself whose day job is not programming. In the specific examples of markdown and date picking mentioned, there are already enough variations in markdown to make writing a universal markdown plugin in wikitext a bit of a challenge since there are already many competing markdown flavors. Inevitably any markdown plugin is going to have to choose to limit themselves in terms of what specific syntax they support.

As for date picking I am not as familiar with it, but I would also imagine there are enough difficulties where using an existing JavaScript library in a plugin is easier than writing something in pure wikitext.

#38

If you are preaching, then I am your choir.

But I confess: I am a programmer. However, I cannot stand javascript. I have no choice but to stare in javascripts eyeballs for my BASIC Anywhere Machine project (the BASIC interpreter is written in javascript, and I am modifying the original product quite heavily), but I can only handle that in small doses and quickly become miserable. (I am some grateful, though, for javascript, the good stuff created with it, and the folk who build the good stuff with it.)

Hence my joy doing things in TiddlyWiki with all of the TiddlyWiki goodness. It works how I think.

#39

Ciao @TW_Tones,

I can’t add much to this thread. I do have one comment from experience …

Regarding WikiText for tables: it is brilliant! But IF I want to SORT a resultant table by click on the header row? Which is easier?

  1. … a rendered TW delving of values with sorting;
    or …
  2. a after (first) render of screen, values re-sorted via JavaScript script?

It depends on the USE purposes. Both methods work.

Often the JS approach here seems apposite (and “economical”)?
But note that the WikiText of a table is fully compatible with a JS afterthought.

In brief: I see no struggle.

Very best wishes
TT

#40

I appreciate your View @TiddlyTweeter, To be clear, I never said JavaScript solutions were out, I made a number of caveats and said if it cant be done in Native TiddlyWiki we should try and get at least the “primitive’s” available in the core, in fact many are already there, they just need to be surfaced for all TiddlyWiki users. In fact many core improvement’s involve JavaScript, and some JavaScript solutions should remain plugins, for good reason.

As we address any gaps in the core that force us to use plugins it will make writing future plugins easier because they do not need to reinvent the wheel because the primitives are available in the core.

  • This is in fact what already occurs a lot, just look at want the core developers do every release. They address the gaps in the core.

A point I have tried to make, and some do seem to understand, is if every plugin needs to write code to address a gap in the core then each of these plugins try and do the same thing themselves, and do it different ways. It is great people can do this, at least until we enhance the core.

All we need is an emphasis on people writing new solutions to seek help, checking if some of the features they want are already available and if not, if they can identify those that should be available to everyone, and every plugin in the future.

  • We need people to think about this and take this matter of architecture into account and if necessary seek assistance from those who can help.
  • It was my observation this does not happen as much as it could, and its a loss to us all, if we do not find a way to at least improve this.
    • It is also a big ask that when someone requires a basic feature for them to have to search for plugins, compare them, see which come closest to what they are seeking when trying to get a feature, one that deserves to be in the core.

Seriously I am about to give up trying to communicate this idea because it causes me grief and anxiety when I see another reply to this thread, I just don’t know if someone is going to criticise me, my words or actually engage with the ideas, even if it is to hold a different view.

  • As it gets longer I am sure people possibly don’t read or follow the conversation with enough consideration, to see my previous response’s.
  • :frowning_face:
1 Like