Poll -- Add TAB-key / character to the TW default editor

#1

Hi folks,
I did just create a Feature Request at GH: [IDEA] It is proposed to add the TAB key / character to the editor and toolbar #7778

The behaviour when the TAB-button is pressed should be as follows:

Updated (23.10.10) Proposal

  • There should be 2 new buttons eg: 273841254-b1d491fb-628a-42ef-a8a8-a13b3a1ace2e with 2 independent functions
    • 1 button for indent, 1 button for dedent
    • 2 buttons are needed for mobile devices
  • The “indent” button will increase the indentation by 1 level for the line where the cursor is placed.
    • If more lines are selected the level will be increased for those lines.
    • It’s not needed to select the whole line to use indent and dedent
  • The “dedent” button removes 1 indent level for 1 or more lines
  • It should be possible to use TAB and SHIFT-TAB keyboard shortcuts with only 1 button visible.
  • The keyboard shortcuts should be configurable from the ControlPanel → Keyboard Shortcut page
Original (now outdated) Proposal
  • Insert TAB character at current cursor position
  • If any text is selected in 1 line
    • Indent the line
    • if SHIFT key is active de-dent the line
  • If any test in multiple lines is selected
    • Indent all lines
    • if SHIFT key is active de-dent all lines

If you support this feature request, than give it a “thumbs up” +1

-mario

1 Like
#2

Related conversation: How to Use the TAB Button in the Editor

#3

I did just update the OP with a new spec due to feedback from GitHub

#4

From GH reply:

In order not to mess with the default (accessibility related?) behavior of jumping between fields with TAB-key, there are two solutions:

  • TAB-button is visible in the editor toolbar by default (user can insert tabs by clicking it), but has no keyboard shortcut bound to it.
  • TAB-button has the shortcuts keyboard Tab/Shift Tab bound to it, but it is by default hidden from the editor toolbar (making the keyboard shortcuts inactive).

According to the text above, I did add a poll so you can vote, what you would prefer?

Select 1 option:

  • Buttons visible – Keyboard shortcuts assigned: Yes
  • Buttons visible – Keyboard shortcuts assigned: No
  • Buttons not visible – Shortcuts assigned: Yes
  • Buttons not visible – Shortcuts assigned: No

0 voters

have fun!
mario

#5

Just for clarity, are you asking which setting would I personally use, or which I think should be the default one? I assume the second question.

Here’re my thoughts about the two options that I suggested:

Buttons hidden, shortcuts assigned – requires less clicks to activate, just checking the two buttons in the config of editor toolbar. But it also makes existence of this functionality hidden away from the users not willing to tinker with the config much.

Buttons visible, shortcuts not assigned – requires more clicks/keypresses to add the keyboard shortcuts. But the existence of the functionality will be immediately apparent to everyone (buttons in toolbar) and the users caring about keyboard shortcuts in the editor are probably also the ones who are more familiar with toolbar and shortcuts configuration.

So I selected buttons visible, shortcuts not assigned, hoping it helps the new and not-willing-to-dig-in-config users discover this functionality, even though for me personally buttons invisible, shortcuts assigned (or even buttons visible, shortcuts assigned) would be better.

#6

For me that’s the same thing. I would like to have Buttons visible and Shortcuts assigned by default.

#7

I hope tools such as the autolist and indenting of * # etc… would still work or are they mutually exclucive?

  • If so an editor toolobar button toggle this behaviour would be idea with the current behaviour default, toggle to insert real tabs.
  • Will wiki text honor the tabs?
#8

Will this be block paragraph indent? Or just “first line of paragraph” indent?

#9

It does not change the behaviour of how HTML is shown by browsers. HTML does ignore whitespace. So indentation will only improve the readability of the plain text in edit mode.

In TW view mode, the tab character will only be seen inside code examples eg:

```
<$let a=10>
	<$list filter="" ... >
		<<currentTiddler>>
	</$list>
</$let>
```

The rendered output will not have any indentation.

#10

At the moment if you type TAB it will jump to the next input field. That will change. – I do not know “autolist”. It’s not a TW core function so it will not change.

TW wikitext syntax will not be changed. The function should add the possibility to add the TAB character into the text area. So lists will still use the same syntax using 1 or more * to define the level. eg:

* list 
	** list level 1
** list level 1

will create the following output at TW:

  • list
    • list level 1
    • list level 1
#11

@pmario I see you also published this How to Use the TAB Button in the Editor

However the current tiddlerwiki defaut behaviour is to tab to the next field. Autolist is one of the plugins that makes use of this default behaviour, that may break when what you propose is implemented.

  • It is for me an essential tool. Using # or * - tab, it will indent to ## or **, shift-tab reverses and on a non empty line continues the next line with the proceeding prefix eg **.
  • I would be fine if the behaviour you propose can be toggled on and off, ideal per tiddlers, ideally in the editor toolbar.
  • For all I know the two features may work together.
  • Here it is for you to look at, Editor AutoLists — it is one of @saqimtiaz’s, I think you may like it as much as I do. But I have a later 0.1.14 version in my plugin wiki, than on that site.
    • @saqimtiaz if you revisit that tool, it would be cool if we could provide additional characters in a config tiddler.
    • I have actually extended autolist to do the same with \*|·|!|:|# to great benefit.
      • I edited $:/plugins/sq/editor-autolist/editor-operation-autolist.js in a couple of places.

[Edited]
Could there not also be an option to allow tab to be recognised by the wiki text parser? to indent a configured number of characters if encountered?

#12

Why should it break. It allows you to define the keyboard shortcut that activates it.
The same is true for the TAB-function

That should be possible. IMO autolist does the same. If there is no “special” character at the beginning of the line it inserts a TAB. If there is a special character it insert that one. It should be possible to make it completely configurable.

#13

As already mentioned it seems that on a general level, AutoLists has exact the functionality that OP is aiming for, that is adding /removing certain characters (tabs, asterisks, pounds) from line beginning upon pressing Tab/Shift+Tab.

AutoLists also does something, that so far has not been discussed, but I think is an important for easy use of indentation. AL applies the list level of the current line to a new line when pressing Enter. CodeMirror does the same for indentation. This is something not possible with just having buttons/shortcuts for tab/shift+tab.

Perhaps adding indentation support to AL plugin is a good start? It seems like a lot of underlying functionality is already there. The list thing may even be more relevant for a non-coding user, who would use lists in their notes frequently, but not have need for code indentation.

We’re running into the problem mentioned by Jeremy on GitHub (repeating functionality of an advanced editor like CM), but:

  • CM doesn’t play well on mobile. Unless this is easily solvable (with the new CM6 perhaps), I see the need for improvements to the core editor. I don’t even mean that I necessarily all those indentation functionality on mobile, just that I’d like a usable editor on mobile (which CM is currently not) that also does nice things on desktop.
  • CM doesn’t support TW-specific things like the lists, tables.
  • CM is heavy and unreasonable if someone needs only a couple of things like lists and indentation.

So ideally we would have everything needed in TW in CM (or its subplugins) and CM would do well on mobile. But since that doesn’t seem to be happening anytime soon, perhaps a plugin like AL+tabs is a good middle ground for now. And if it turns out to be practical, it could be turned to a core plugin in the future.

1 Like
#14

Thanks for the feedback everyone.

TLDR;
May be I do have to completely rewrite and re-think the “feature request”.

I’ll close this thread and the poll. I’ll probably open a new rewritten one soon.

I think the auto-creation of the same list level as the last line on [Enter] would be an advantage for every user.

The indent and dedent shortcuts of AL could also be different to the TAB-key.

Using the TAB key activated by default will have a very low chance, since it creates an accessibitlity problem.

The problem with auto-list is, that it does contain JS code. So it cannot be imported to tiddlywiki.com without a browser reload. So it’s kind of useless for the intention of the OP.

What I could see – The needed js-functions could be implemented into the core. So it would be possible to create plugins that do contain wikitext only. So they can be imported without a browser reload.

The problem for “unused” js-code is, that Jeremy does not like new core-code, if the core UI does not use it.

So we probably have a classical “chicken – egg problem” here.

#15