Re: [scite] Help on using ListBoxx
Yan Feng wrote: I need a new ListBoxx window in SCite IDE ,but I don't know how to instance the object like ListBoxX lbx the VC++ always told me no ListBoxX declared. It is declared and defined in PlatWin.cxx - and it is known to VS 2005, but then I am using local project and solution files. I don't think current ones are maintained for SciTE, but you could take the older ones from the source distribution and adapt them. Robert Roessler [EMAIL PROTECTED] http://www.rftp.com ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] replace in many files at once
Hi, I use SciTE (1.72) to write programs. I have many files open at once in the same session. I wonder if it is possible to do a replace in all the open files at once, for example to change a function name in all the files of the program. ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] replace in many files at once
You will have to turn on the advanced find-and-replace dialogue, though. find.replace.advanced=1 On 6/29/07, Robert Roessler [EMAIL PROTECTED] wrote: Jerome Blondel wrote: I use SciTE (1.72) to write programs. I have many files open at once in the same session. I wonder if it is possible to do a replace in all the open files at once, for example to change a function name in all the files of the program. Well, 1.74 certainly has the Replace in Buffers option on the Replace dialog on Windows XP. Robert Roessler [EMAIL PROTECTED] http://www.rftp.com -- Nis Donatzsky Hansen http://www.anaerob.dk Religion is the most malevolent of all mind viruses. - Arthur C. Clarke ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] SciTE text selection and VMware tools copy paste
Good evening, I hope I am not too off-topic with this question, but the problem seems to be SciTE-specific, even though not necessarily a bug. I use a debian'ish Linux (Elive) from within VMware Player 2 on a WinXP host. VMware tools are installed and working, i.e. copy paste to/from the VM and the host system works as expected, with one notable exception: I cannot copy any selected text directly out of SciTE's window to my host system, while pasting something into SciTe from WinXP works. Copying stuff from terminal sessions, other editors like NEdit etc. works. What I do at the moment is rather awkward: mouse-select text, paste into NEdit or terminal window, select again there and paste into my Windows application. The reason for this (non-)behaviour must be in the way SciTE handles text buffers and/or selections. Any ideas? Can this be fixed or worked around somehow? Regards -- Alexander Kriegisch ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
[scite] TeX (was: Re: Re: Re: [scintilla] styler.GetPropertyInt and keywordlists)
instanton: After carefully inspecting the ColouriseTeXDoc code I realized that the keywordlists are not used most of the time because most TeX files would not begin with a comment line like %interface=tex or interface=latex and the like. I don't use TeX so just assume the people that contribute code know what they are doing. This becomes difficult when there are multiple ways of using a language and communities built around particular libraries as I can't judge the benefits or drawbacks. In some cases (e.g. for users using UTF8 encoding), the first line of the document must be used for other purposes (e.g. putting %# -*- coding: utf-8 -*- there in order that SciTE recognize the document as being written in UTF8 encoding) The encoding cookie should work on line 2 as well. So I'm wondering if you would accept the idea of replacing ColouriseTeXDoc code in LexTeX.cxx with something similar to ColoriseLaTeXDoc from LexOthers.cxx. To preserve current usage, it would be safer to implement a second lexer in LexTeX.cxx and allow users to choose between the two. If there are other TeX users on this list or the scite-interest list then they should make their opinions known. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Help on using ListBoxx
Yan Feng: I need a new ListBoxx window in SCite IDE ,but I don't know how to instance the object like ListBoxX lbx the VC++ always told me no ListBoxX declared. You shouldn't use ListBoxX directly from SciTE as it is contained within Scintilla and exposed using the autocompletion APIs. Have a look at SCI_AUTOCSHOW. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Single instance and Director Extension in SciTEGTK
Chachereau Nicolas: I think we should decide in which way SciTE reacts when it is sent a message. I think SciTE should be raised above the other windows in some cases, like: find:, goto:, insert:, loadsession:, macrocommand:, macrolist:, menucommand:, open:, output:, replaceall: Fronting windows with insufficient reason became such a problem on Windows that recent versions of Windows try to stop applications fronting themselves except in particular cases. SciTE should not be fronted by default for most of these commands as they damage use cases where SciTE is being controlled by a foreground application that wants to retain focus over a sequence of actions. How strict should we be about the closing: message? If there are any unsaved files, and the user cancels the quit, should SciTE send a message to tell the director it didn't quit? Or should it be impossible for the user to cancel a quit when the director is closing? There should probably be an alternative command for one or the other since it depends on the controlling application. I don't really like the assumption that a process can only communicate with SciTE if it started it. I think a process should be able to become a director even after SciTE started. Say you have a director application along with SciTE instances attached to it. You don't want the director to interfere with SciTE instances that you (or another director) started independently. To achieve this, we may have to change the method we use for IPC. Most of my thinking about the director interface was on Windows where WM_COPYDATA can be broadcast to all windows or sent to one in particular. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] SciTE text selection and VMware tools copy paste
Alexander Kriegisch: I use a debian'ish Linux (Elive) from within VMware Player 2 on a WinXP host. VMware tools are installed and working, i.e. copy paste to/from the VM and the host system works as expected, with one notable exception: I cannot copy any selected text directly out of SciTE's window to my host system, while pasting something into SciTe from WinXP works. There have been reports of copying from Scintilla/SciTE to other applications (aterm IIRC) not working so there may be something that could be fixed if anyone is sufficiently interested in debugging this. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] Re: Minimal way to export Lua symbols from SciTE
steve donovan: Right - I made a linker version script by whacking the lua.symbols And building with -rdynamic -Wl,--version-script lua.map Still works! The executable is a bit larger ;) but not as big as -rdynamic on its own. Builds for me too. Are all the Lua users happy enough with this for it to be committed? Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] File type patterns like Makefile* do not work
Alexander Kriegisch: file.patterns.make=makefile*;Makefile*;*.mak;configure*;*.mk SciTE globs can only match '*' as a prefix, not as a suffix. I will remove configure* from others.properties. Neil ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
Re: [scite] File type patterns like Makefile* do not work
file.patterns.make=makefile*;Makefile*;*.mak;configure*;*.mk SciTE globs can only match '*' as a prefix, not as a suffix. I will remove configure* from others.properties. Well, then why does it work with SciTE for Windows systems? Would you consider making it work on Linux as well instead of removing configure*? It would be a benefit, because there are many cases in which you want to match something.* or even something*, because there might be numbers in the extension like logfile.123 or similar. Nobody can possibly define n extensions for all possible numbers, can they? ;-) ___ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
