with
@bool scripting-abbreviations = False
and
,,={|{x='__NEXT_PLACEHOLDER'}|}
in @data abbreviations
my abbrev prints
width="width" height="<|height|>"
width is selected. I enter 200 for width, then double comma and get
width="200{|{x='__NEXT_PLACEHOLDER'}|}" height="height"
So it seems to me that next placeholder depends on scripting-abbreviations=True
declaring
@string next-placeholder-abbrev = ,,
with scripting turned off didn't work for me
Since scripting-abbreviations is the security risk, I was wondering if the
next-field capability could be implemented without scripting-abbreviations
being active.
That would provide rich abbreviations without having to cross the
line to full scripting.
Hope that makes sense.
On Fri, Nov 13, 2015 at 1:06 PM, Edward K. Ream <[email protected]> wrote:
> On Fri, Nov 13, 2015 at 12:33 PM, Kent Tenney <[email protected]> wrote:
>>
>> Terry's suggestion of substitution only, no code sounds doable.
>> Would it be possible to provide next-field by some means
>> other than via code-running?
>
>
> I'm not sure I understand this question :-)
>
> Leo's (static) abbreviation code is in: leoPy.leo#Code-->
> Command classes-->@file ../commands/abbrevCommands.py-->
> abbrev.expandAbbrev & helpers (entry point)
>
> This is complicated code, but the code that does next-field is not likely to
> be a security concern. Afaik, the only security concern are:
>
> 1. scripting abbreviations such as:
>
> date;;={|{import time ; x=time.asctime()}|}
>
> 2. The code in @data abbreviations-subst-env nodes.
>
> As has been said, a case can be made for default locks on scripting,
> although Leo's scripting capabilities are powerful enough that people must
> take care when using .leo files that are not their own. You had better look
> twice at the code for an @button node that says "push me".
>
> Imo, the only real "security" is knowing who it is that has given you a .leo
> file. In many cases, the github id is enough to identify the person
> responsible for code. But you are asking for big big trouble if you use an
> "untrusted" .leo file.
>
> BTW, Leo already has a lock that prevents a .leo file from enabling @script
> nodes. unitTest.leo prints the following on entry:
>
> Security warning! Ignoring...
> @bool scripting-at-script-nodes = True
>
> Imo, this is the minimum required. I suspect that abbreviation settings are
> honored in regular .leo files, so there could be a concern if, say, ",,"
> were replaced by a regular character. But once again, @button nodes would
> be a very easy way to cause execution of malicious code.
>
> EKR
>
> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/leo-editor.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
