[texworks] Unwanted side-effect of <tab> : how to avoid ?

[Paul A Norman]

Hi,

I was thinking that it may be necessary to allow for more than one
auto-completion file at  a time.

People are able to write their own specialist needs and general
subsets as well (even copy and paste to smaller files and  do away
with, or comment, tw-latex.txt if you want to reduce any perceived
redundant options for your/team needs.

For example, I can write completion files up as necessary macros (when
QtScript is not being used for interaction on content) for any major
.sty we write ourselves (or any special package used) e.g...

cp:={\cappar #INS#}
dp:=\doDropCap{#INS#}
rH:=\ReverseHeading% No Logos, Drop Cap Paragragh, Line, or TOC
entry#RET#% Use \coma for printing , in Heading or sub heading#RET#
[#RET#  TopHeading = #INS#text,#RET#  SubHeading = •text,#RET#
subLine = false,#RET#   putinToc = true#RET# ]#RET#  {•double column
section main story
text}#RET#\begin{multicols}{\value{columns}}#RET#•#RET#\end{multicols}

That is why I was thinking of a check box list populated from the
configuration/completion directory.
It would help reduce the number of options showing on the tab key to
what is currently useful for any User.

Paul

On 14 June 2011 12:46, Herbert Schulz <herbs at wideopenwest.com> wrote:
>
> On Jun 13, 2011, at 7:38 PM, Paul A Norman wrote:
>
>> Hi,
>>
>> At a pinch I wouldn't mind even a drop down type widget with checkable
>> boxes that lets me choose which completion scenarios to use.
>>
>> Else as I wrote earlier how does Tw know I'm working directly on a
>> bibliography file etc etc?
>>
>> That's pretty well much Typesetting Engine independent as are some other things.
>>
>> Paul
>>
>>
>>
>> On 14 June 2011 10:40, Philip TAYLOR (Webmaster, Ret'd)
>> <P.Taylor at rhul.ac.uk> wrote:
>>>
>>>
>>> Reinhard Kotucha wrote:
>>>
>>>> Even if you specify a particular engine, it's still not clear which
>>>> type of file you want to process.  Suppose you select "plain TeX" but
>>>> the file contains the line "\input texinfo.tex".  After loading this
>>>> file, the escape character is "@" instead of "\".  This breaks command
>>>> completion and syntax highlighting and it's extremely difficult for an
>>>> editor to find out what to do.
>>>>
>>>> The problem you reported is a good example.  Plain TeX can more or
>>>> less considered as a programming language, whereas LaTeX is supposed
>>>> to be a markup language, i.e. a file format.  One would expect then
>>>> that it's easier to support command completion and syntax highlighting
>>>> in LaTeX.  This is definitely true, but Beamer re-defines standard
>>>> LaTeX list environments.  Hence, if you want to provide proper command
>>>> completion and syntax highlighting, you have to evaluate the whole
>>>> file.
>>>
>>> Yes, I agree that no matter which engine you select, you /may/
>>> have a pathological file that does not follow the normal markup
>>> pattern for that engine, so in an ideal world you could then
>>> switch auto-completion on the fly.  But a default behaviour that
>>> uses the engine to determine which set of auto-completes is
>>> most likely to be relevant is surely not an unreasonable
>>> behaviour, is it ?
>>>
>>> ** Phil.
>>>
>>
>
> Howdy,
>
> The command-completion file would have to be related to the extension of the file being edited and also the default engine being used to compile that file via the
>
> % !TEX program = xxxxx
>
> line. The other way to do it would simply be to have another ``magic line'' that defined which command completion file to use; that would probably be the easiest thing to do. E.g.,
>
> % !TEX commandcompletion = xxxxx
>
> with xxxxx being latex, etc. I'd suggest that the default commandcompletion (i.e., when no line is given) is latex only because that is the most common use.
>
> Good Luck,
>
> Herb Schulz
> (herbs at wideopenwest dot com)
>
>
>
>
>